[レポート] Amazon DynamoDB Deep Dive: より進んだDynamoDBのデザインパターン #reinvent

本ブログエントリはre:Invent 2018のセッション「Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB」の参加レポートです。

AWS re:Invent 2018

#Amazon DynamoDB

#AWS

yoshihitoh

2018.11.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

福岡のyoshihitohです。re:Invent 2018のセッション「Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB」についてレポートします。

セッション情報

セッション名

Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB

スピーカー

Rick Houlihan - Principal Technologist, NoSQL

概要

原文の引用です。

This session is for those who already have some familiarity with DynamoDB. The patterns and data models discussed in this session summarize a collection of implementations and best practices leveraged by Amazon.com to deliver highly scalable solutions for a wide variety of business problems. The session also covers strategies for global secondary index sharding and index overloading, scalable graph processing with materialized queries, relational modeling with composite keys, and executing transactional workflows on DynamoDB.

以降がセッション内容です。

DynamoDB Deep Dive: より進んだDynamoDBのデザインパターン

アジェンダ

データ処理の簡単な歴史 (なんでNoSQL?)
DynamoDBの概要
NoSQLのデータモデリング
- 正規化 vs 非正規化
NoSQL共通のデザインパターン
- 複合キー
- 階層データ
- リレーショナルデータ
実際のアプリケーションのモデリング

データ処理の歴史

データベース技術のタイムライン

技術の適用と誇張の曲線

なんでNoSQL?

SQL	NoSQL
保存に特化	計算に特化
アドホックなクエリ	インスタンス化したビュー
垂直スケーリング	水平スケーリング
OLAP向き	スケールするOLTP向き

Amazon DynamoDB

特徴

フルマネージドなNoSQL
ドキュメント型・もしくはキー・バリュー型
どんなワークロードでもスケールする
高速かつ一貫性がある
アクセス制御できる
イベント駆動のプログラミング

テーブルの構造

パーティションキー

アイテムを一意に識別する
順序のないハッシュのインデクスとして使われる
テーブルをパーティション化してスケールできるようにする

パーティション: ソートキー

2つの属性を組み合わせてアイテムを一意に識別する
順序のないハッシュインデクスキーが同一のアイテムについて、ソートキー順にデータを並べる
パティションキー1個につき何個でもソートキーを持てる
- ただしセカンダリインデクスがある場合は除く

パーティションはそれぞれ3つずつレプリケートされる

ローカルセカンダリインデクス(LSI)

ソートキーに代替の属性を使う
インデクスは１つのパーティションキーに対してローカル
LSIを使う場合、パーティションキー1つのつき10BMまで

グローバルセカンダリインデクス(GSI)

代替のハッシュキーを使う
ソートキーを使う場合は同一もしくは代替の属性を使う
インデクスは全てのパーティションキーにまたがる
複合インデクスを使う場合は複合キーを用意する
LSIを使う場合、パーティションキー1つのつき10BMまで

グローバルセカンダリインデクスの更新はどうやって動いてる？

クライアント → テーブル: 更新リクエストを投げる
クライアント ← テーブル: 更新レスポンスを返す
テーブル → GSI: 非同期更新を開始する

GSIのWCUが不足している場合、テーブルへの書き込みがスロットルされる

NoSQLのスケーリング

NoSQLをうまく使っていない場合

ホットパーティションにアクセスが集中している

うまく使ってる場合

アクセスを均等に分散させている

自動スケール

実際のトラフィックに応じてスループットを自動調整する

NoSQLのデータモデリング

リレーショナルなデータの例

SQL vs NoSQLのデザインパターン

NoSQLでは正規化しない

Amazon DynamoDBの主要なコンセプト

パーティションキー
- パーティションキーを選択する
  - 重複なしの値を大量に
  - アイテムは均一にリクエストされ、ランダムに分散する
- 例
  - 悪い値: ステータス、性別
  - 良い値: カスタマーID、デバイスID
ソートキー
- ソートキーを選択する
  - モデルは1:NとN:Nの関連にする
  - Efficient/selectiveパターン
    - 複数のエンティティをクエリする
- 例
  - Orders
  - OrderItems

true/falseのような値など、カーディナリティが低い(取りうる値域が狭い)ものは適さない

NoSQLデータモデリングの教義

ユースケースを学ぶ
- アプリケーションの性質
  - OLTP
  - OLAP
  - DSS
アクセスパターンを明確にする
- データソースを明確にする
- クエリ集約を定義する
- すべてのワークフローをドキュメント化する
データモデリング
- リレーショナルモデルを避ける (1つのテーブルを使う)
- アプリケーションサービス1つにつき、テーブル1個
  - テーブル間でいったりきたりするのを避ける
  - アクセスパスを単純化する
- 主キーを明確にする
  - アイテムがどれくらい追加・参照されそうか
  - パーティションで負荷を散らす
- 主要でないアクセスパターンにインデクスを定義する
レビューして上記プロセスを繰り返す

複合キー

アプローチ1: クエリフィルターを使う

アプローチ2: 複合キーを使う

Status と Date を組み合わせる

より進んだデータモデリング

OLTPアプリケーションでどのようにデータを使うか

ほとんど階層構造
エンティティ駆動のワークフロー
データが複数のテーブルに分散する
複雑なクエリが必要になる
ACIDがメイン

バージョン履歴を管理する場合の例

リレーショナルなトランザクションをマッピングする

設定管理サービス
- ResolerGroup
- Contacts
- Configuration Items
トランザクションなワークフロー
- Config Items を Resolver Group に追加する
- Config Item の status を更新する
- Contacts を Resolver Group に追加する

DynamoDB Transactions API

TransactWriteItems
- 同期更新 (update/put/delete)
  - アトミック
  - 自動ロールバック
- 1トランザクションで10アイテムまで
- 複数テーブルをサポート
- 複雑な条件チェック
良いユースケース
- 複数のアイテムをまたいで更新する場合
- 条件付きのバッチ更新
悪いユースケース
- 正規化データをメンテナンスするため